1. Field of the Invention
This invention generally relates to a user interface (UI) device and, more particularly, to a UI using a database of rules to send validated requests to a service device to fulfill.
2. Description of the Related Art
In many user interfaces that select optional parameter settings, not all combinations of settings are valid. In a model-view controller UI design there are two entities; a rules-based state machine (i.e. the model) and the view controller. This is a master-slave relationship where the model state machine tells the view controller what to display and how to display it. Take for example the UI for a conventional multi-functional peripheral (MFP), which may perform among many other possible tasks, printing or copying. The model runs on one processor and the view controller runs on another processor. The view controller “draws” the UI screen, based on information provided by the model controller. Each time the user selects a button on the UI, the view controller checks with the model controller to learn what to change on the screen, if anything at all. Using the model-view controller architecture, the options shown in the UI are always accurate and up to date. It is not (or should not be) possible to choose an invalid setting. But this feature comes at the cost of performance-sapping and verbose real-time event communication between the model and view controllers.
Service oriented architecture (SOA) software architecture is based on discrete pieces of software providing application functionality as services to other devices or applications. A service is a self-contained unit of functionality, such as printing a document. SOA makes it easy for devices and applications connected over a network to cooperate without the need to make changes to the underlying program itself.
The purpose of SOA is to allow users to combine together fairly large chunks of functionality to form ad hoc applications built almost entirely from existing software services. The main benefit of SOA is to allow simultaneous use and easy mutual data exchange between programs of different vendors without additional programming or making changes to the services.
With SOA, an application UI interacts with the user to select optional parameter settings. Generally, the UI assumes that all setting combinations are valid, because it has limited knowledge of the rules that constrain the device or service. The user-selected settings are gathered into a “job ticket” and submitted to the service device for “validation”. If the job ticket is rejected because it contains invalid or inconsistent settings, there is little, if any, useful information available to the user that helps to correct the problem.
One classic UI element that locally implements a constraint rule is the graphical user interface (GUI) “radio button”. This setting allows the user to select one (but only one) of many optional settings. Any previously selected radio button in the same group becomes deselected. Common user interfaces incorporate many radio button elements; separating the settings within a single radio button but not constraining setting combinations between multiple radio buttons.
Rules engines have traditionally been used by “truth finding” or “inference” expert systems and to implement business “production rules” (a.k.a. “work flow”). In logic, an inference rule is a logical form consisting of a function which takes premises, analyzes their syntax, and returns a conclusion (or conclusions). For example, the rule of inference called modus ponens takes two premises, one in the form “If p then q” and another in the form “p”, and returns the conclusion “q”. The rule is valid with respect to the semantics of classical logic, in the sense that if the premises are true (under an interpretation), then so is the conclusion.
It would be advantageous if a method existed that insured a valid combination of optional settings even when the device that displays a UI is separated from the device or services it controls.